REMARKS 

The Office Action dated December 10, 2008, has been received and carefully 
noted. The above amendments to the claims, and the following remarks, are submitted as 
a full and complete response thereto. 

Claims 1 and 24-63 are currently pending in the application, of which claims 1 and 
24-27 are independent claims. Claims 1 and 24-27 have been amended, and claims 28-63 
have been added, to more particularly point out and distinctly claim the invention. 
Claims 2-23 have been cancelled without prejudice or disclaimer. Claims 1 and 24-63 
are respectfully submitted for consideration. 

Double Patenting Rejection 

The Office Action rejected claims 1-8, 18, and 24-27 under the judicially created 
doctrine of non-statutory obviousness-type double patenting over claims 1, 2, 4-9, 19 and 
20 of U.S. Patent No. 7,313,136 ("the '136 patent"). 

Applicant submits the attached, properly executed terminal disclaimer with respect 
to U.S. Patent 7,313,136 in compliance with 37 C.F.R. §1.321(c). As such, Applicant 
respectfully submits that the double patenting rejection is rendered moot. 

Accordingly, Applicant respectfully requests withdrawal of the non-statutory 
obviousness-type double patenting rejection. Applicant respectfully submits that claims 
1-8, 18, and 24-27 are now in condition for allowance. 
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Specification 

The Office Action objected to the abstract of the specification because it was not 
on a separate sheet. That particular requirement is not germane to the present application, 
because the present application is a national stage filing of a PCT application. 
Nevertheless, minor amendments to the abstract have been made, and it is respectfully 
submitted that the abstract currently complies with all relevant regulations. Withdrawal 
of the objection is respectfully requested. 

Claim Objections 

The Office Action objected to claims 1-17, 24, 25 and 27 because of minor 
informalities. Specifically, the Office Action objected to the use of "adapted" in claim 1, 
objected to the lack of clarity of the expression "said second segment further comprises a 
sequence and acknowledge field is adapted to inform," raised a question about the 
dependency of claim 14, and the remainder of the claims were objected to based on the 
objections to a base claim from which they depend. 

Claims 2-17 have been cancelled without prejudice or disclaimer, and 
consequently the objection to those claims is moot and should be withdrawn. Claims 1, 
24-25, and 27 have been amended to avoid the use of the term "adapted." Thus, the 
objection on the basis of the term "adapted" is moot and should be withdrawn. Claim 14 
has been cancelled and consequently questions about its dependency are moot, as is the 
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corresponding objection. Withdrawal, therefore, of each of the objections to the claims is 
respectfully requested. 

Claim Rejections under 35 U.S.C. §112, Second Paragraph 

The Office Action rejected claims 2, 5, and 20 under 35 U.S.C. §112, second 
paragraph, as allegedly being indefinite for failing to particularly point out and distinctly 
claim the subject matter which Applicant regards as the invention. Claims 2, 5, and 20 
have been cancelled without prejudice or disclaimer. Thus, the rejections of claims 2, 5, 
and 20 are moot and withdrawal of the rejections is respectfully requested. 

Claim Rejections under 35 U.S.C. § 101 

The Office Action rejected claims 18-27 under 35 U.S.C. § 101 as allegedly being 
directed toward non-statutory subject matter. Specifically, with respect to claims 18-23, 
the Office Action alleged that the claims are non-statutory because they are directed to a 
"data package," which is a data structure per se. Claims 18-23 have been cancelled 
without prejudice or disclaimer. Thus, it is respectfully requested that the rejection of 
claims 18-23 be withdrawn as moot. 

With respect to claim 26, the Office Action alleged that the claim is not tied to 
another statutory category and does not transform underlying subject matter. The test 
being applied is an outdated test, but is similar to the "machine-or-transformation" test 
imposed by the U.S. Court of Appeals for the Federal Circuit in the case of In re Bilski. 
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Claim 26, as presently pending, meets the Bilski test for statutory subject matter. 
Withdrawal of the rejection of claim 26 is respectfully requested. 

As to claim 27, the Office Action alleged that the limitation "computer program" 
is not within a statutory category and that there is no "physical structure/connection of 
computer software recited in the claim." Claim 27, as presently pending, recites statutory 
subject matter, since the claimed computer program is "embodied on a computer-readable 
storage medium," which falls within the statutory category of "manufacture." Thus, it is 
respectfully requested that the rejection of claim 27 be withdrawn. 

Claim Rejections under 35 U.S. C. §103 (a) 
Claims 1-2, 4-6, 18-21, and 24-27 

The Office Action rejected claims 1-2, 4-6, 18-21, and 24-27 under 35 U.S.C. 
§103(a) as being allegedly unpatentable over U.S. Patent No. 6,219,697 of Lawande et al 
("Lawande"). The Office Action acknowledged that not all of the claim features are 
disclosed by Lawande, but asserted that the remaining features would have been obvious. 
Claims 2, 4-6, 18-21 have been cancelled without prejudice or disclaimer. Applicants 
respectfully submit that claims 1 and 24-27 recite subject matter that is neither disclosed 
nor suggested in Lawande. 

Claim 1 is directed to a system for providing data communication between 
modules connected through a port connector. The modules are configured to 
communicate a data package comprising in a layered structure a physical layer 
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comprising a first and a second segment to encapsulate other layers in said data package. 
The data package also includes in the layered structure a data link layer comprising a first 
header field for data payload type and a second header field for a data link layer version, 
and a network/transport layer comprising a third header field for a transmitting module's 
address, a fourth header field for a length of said data package, a fifth header field for an 
offset value for determination of data payload start in said data package. The data 
package also includes data payload. 

Claim 24, upon which claims 28-41 and 62-63 depend, is directed to an apparatus 
including a receiver configured to receive a data package configured to be communicated 
between modules connected through a port connection. The data package includes, in a 
layered structure, physical layer data comprising a first and a second segment to 
encapsulate other layers in said data package. The data package also includes, in the 
layered structure, data link layer data in a first header field comprising data payload type 
and in a second header field comprising a data link layer version. The data package 
further includes, in the layered structure, network/transport layer data in a third header 
field comprising a transmitting module's address, in a fourth header field comprising a 
length of said data package, in a fifth header field comprising an offset value for 
determination of data payload start in said data package. The data package additionally 
includes data payload. 

Claim 25, upon which claims 42-55 depend, is directed to an apparatus including a 
transmitter configured to transmit a data package configured to be communicated 
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between modules connected through a port connection. The data package includes, in a 
layered structure, physical layer data comprising a first and a second segment to 
encapsulate other layers in said data package. The data package also includes, in the 
layered structure, data link layer data in a first header field comprising data payload type 
and in a second header field comprising a data link layer version. The data package 
further includes, in the layered structure, network/transport layer data in a third header 
field comprising a transmitting module's address, in a fourth header field comprising a 
length of said data package, in a fifth header field comprising an offset value for 
determination of data payload start in said data package. The data package additionally 
includes data payload. 

Claim 26, upon which claims 56-61 depend, is directed to a method including 
establishing, by a transmitter, data communication between modules connected through a 
port connection, wherein said modules each communicate a data package comprising in a 
layered structure a physical layer comprising a first and a second segment to encapsulate 
other layers in said data package. The establishing includes providing, in said data 
package, in a data link layer, a first header field for data payload type and a second 
header field for a data link layer version. The establishing also includes providing, in 
said data package, in a network/transport layer, a third header field for a transmitting 
module's address and a fourth header field for a length of said data package and a fifth 
header field for an offset value for determination of data payload start in said data 
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package. The establishing further includes providing, in said data package, a data 
payload. 

Claim 27 is directed to a computer program embodied on computer-readable 
storage medium and comprising code configured to perform a process when said program 
is run in a processor. The process includes establishing data communication between 
modules connected through a port connection, wherein said modules each communicate a 
data package comprising in a layered structure a physical layer comprising a first and a 
second segment to encapsulate other layers in said data package. The establishing 
includes providing, in said data package, in a data link layer, a first header field for data 
payload type and a second header field for a data link layer version. The establishing 
also includes providing, in said data package, in a network/transport layer, a third header 
field for a transmitting module's address, a fourth header field for a length of said data 
package, and a fifth header field for an offset value for determination of data payload 
start in said data package. The establishing further includes providing, in said data 
package, a data payload. 

Applicant respectfully submits that Lawande fails to disclose or suggest or 
otherwise render obvious all the features of any of the presently pending claims. 

Applicant respectfully submits that the Office Action has attempted to identify 
corresponding elements, for those of claim 1, in Lawande by selecting features of any 
elements without consideration for the factual association described in the description. 
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This is improper, as both the claims and the references must be considered as a whole, 
and the claims must be read in light of the specification. 

Certain embodiments of the present invention involve the provision of a number of 
fields within the header of the transported packet, such as an IP, or OBEX type packet, 
where (on the other hand) Lawande discusses the provision of fields in the header of the 
enveloping layer IEEE 1394. 

From figure 5 of Lawande it is evident that the IP packet is provided on a different 
layer than the Common Packet Header (CPR), which is a part of the IEEE link layer, as 
that term would be understood to one of ordinary skill in the art. Furthermore, in column 
17, in Lawande, it is stated that the protocol IEEE 1394 "has a field in the header which 
has memory information of the target of the packet of the data." However, to integrate 
the two protocols, the field is modified , putting in the "protocoltype" field in the packet 
header. 

Hence, it is clearly shown that the "protocoltype" field according to Lawande is 
located in the header of the IEEE 1394 protocol, whereas the "data payload type" field 
according to certain embodiments of the present invention is located in the header of the 
transported packet, or (more specifically) the data segment. This is further supported in 
the description portion of the present application on page 15, lines 18- 21 : "in this context 
when referring to a header section, the header section of the data segment is meant unless 
specifically stated otherwise." Accordingly, Lawande does not disclose a protocol type 
identifier in the header of the encapsulated data segment. 
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More specifically, certain embodiments of the present invention relate to the 
provision of a "data payload type 55 field in the header of the data segment encapsulated in 
between the two segments of the physical layer referred to in claim 1 and shown (in one 
embodiment) as 12a and 12b in Fig. la. This, however, is not reflected in fig. 7c in 
Lawande, because Lawande does not disclose what is recited in claim 1 . 

Lawande, furthermore, would not lead one of ordinary skill in the art toward the 
claimed invention. Lawande has been considered (by the USPTO) as the closest prior art, 
since it allegedly has some elements in common. The objective problem to be solved by 
a person of ordinary skill in the art in light of Lawande could be characterized as follows: 
How to integrate IEEE 1394 protocols with IP protocols. A person of ordinary skill in 
the art facing this problem could perhaps, in light of Lawande, know how to integrate a 
IEEE 1394 protocol with IP protocols. 

It would not, however, be obvious for a person of ordinary skill in the art to 
provide a header of a data segment with a field specifying the content of said specific 
data segment. More specifically, certain embodiments of the present invention relate to 
the provision of backward and forward compatibility of a data link layer protocol in a 
system of connecting modules through a port connection. Further, another object of 
certain embodiments of the present invention relate to the way of managing packets of a 
number of different protocols simultaneously. These objects (nor any similar) cannot be 
found in the cited art. Thus, the cited art would not lead one of ordinary skill in the art 
toward the claimed invention. 
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Additionally, Lawande does not disclose "an offset value for determination of data 
payload start in said data package." According to the description of the present 
application, on page 5, line 28, to page 6, line 3, the offset value can provide means for 
compensating for future changes to the network/transport protocols, since the receiving 
module (through the offset value) may jump directly to the payload start when the 
receiving module does not require the potential data from the header. 

Furthermore, according to the description of the present application on page 18, 
lines 20-28, the offset field can be incorporated in the header section to make the header 
backward compatible. When future fields are added to the header, any software can 
forward payload data even though the software is aware of the additional fields, since the 
software may forward the data package based on the Offset and the Version field. Hence, 
this field can permit compensation for future extensions of the header section, as there 
might be a need in the future for additional fields in the header. These extensions can be 
added while still being backward compatible, the Offset field will tell the receiving entity 
where the actual data package starts. 

In contrast to the above, and in contrast to the feature "an offset value for 
determination of data payload start in said data package," the common packet header in 
Fig. 7C of Lewande contains a destination offset field in order to comply with the IEEE 
1394's requirement of including memory architecture information. However, the 
reference to ip_fragment_offset in Lewande is a part of the IP protocol, which has to do 
with fragmenting a large non-IP packet into several, smaller IP packets. More 

- 24 - Application No.: 10/571,290 



specifically, to fragment a datagram, the header size is used to calculate how many 
fragments are required. The header of the original datagram is then copied into the 
headers of each of the fragments. The fragment offset reflects the position of the 
fragment within the original datagram. Each fragment becomes its own datagram and is 
routed independently of any other datagrams. This makes it possible for the fragments of 
the original datagram to arrive at the final destination out of order. At the final 
destination, the fragment offset field tells the receiver how to order the fragments. 
Hence, the concept of the Offset field according to the discussion in the present 
application's specification (and recited in claim 1: "an offset value for determination of 
data payload start in said data package") is not disclosed in Lewande. 

Indeed, in Lewande there is nothing that would lead a person skilled in the art 
closer in respect of using an offset field in the way it is used according to the present 
claims. Furthermore, the solution according to Lewande may have a number of 
drawbacks. Firstly, the protocoljype field is multiplexed with the memory information 
field, making it complex when decoding the field. Secondly, the solution according to 
Lewande renders it difficult or impossible to mix different protocol types in the same 
connection. Lewande is specifically designed for transfer of IP messages, whereas 
certain embodiments of the present invention allow a combination of multiple protocols 
sent simultaneously on the same connection without resetting or changing its state. For 
instance, OBEX and IP packages can be sent alternating in respect to each other without 
resetting the connection. 
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Hence it is respectfully submitted that the subject-matter of the claimed invention 
in claim 1 is not obvious in view of Lewande. Although each of the independent claims 
has its own unique scope, the same reasoning as for independent claim 1 is also valid for 
each of independent claims 24-27, as they contain corresponding features to those 
discussed above, with respect to claim 1. Thus, it is respectfully requested that each of 
the rejections of each of claims 1 and 24-27 be withdrawn. 

Claim 3 

The Office Action rejected claim 3 under 35 U.S.C. § 103(a) as being allegedly 
unpatentable over Lawande in view of U.S. Patent No. 5,572,528 of Shuen ("Shuen"). 
This rejection is moot and its withdrawal is respectfully requested because claim 3 has 
been cancelled without prejudice or disclaimer. 

Claims 7-17 

The Office Action rejected claims 7-17 under 35 U.S.C. § 103(a) as being 
allegedly unpatentable over Lawande in view of U.S. Publication No. 2003/0214928 of 
Chuah ("Chuah"). This rejection is moot and its withdrawal is respectfully requested 
because claims 7-17 have been cancelled without prejudice or disclaimer. 

For the reasons set forth above, it is respectfully submitted that each of claims 1 
and 24-63 recites subject matter that is neither disclosed nor suggested in the cited art. It 
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is 5 therefore, respectfully requested that all of claims 1 and 24-63 be allowed, and that 
this application be passed to issuance. 

If for any reason the Examiner determines that the application is not now in 
condition for allowance, it is respectfully requested that the Examiner contact, by 
telephone, Applicant's undersigned representative at the indicated telephone number to 
arrange for an interview to expedite the disposition of this application. 

In the event this paper is not being timely filed, Applicant respectfully petitions for 
an appropriate extension of time. Any fees for such an extension together with any 
additional fees may be charged to Counsel's Deposit Account 50-2222. 

Respectfully submitted, 




Peter Flanagan 
Attorney for Applicant 
Registration No. 58,178 

Customer No. 32294 

SQUIRE, SANDERS & DEMPSEY LLP 
14™ Floor 

8000 Towers Crescent Drive 
Vienna, Virginia 22182-6212 
Telephone: 703-720-7800 
Fax: 703-720-7802 
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